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A bs tr a ct 

An integrated system for the multidisciplinary 
analysis and optimization of airframe and propulsion 
design parameters is being developed This system 
is known as EPAS, the Integrated 
Propulsion/Airframe Analysis System. The 
traditional method of analysis is one in which the 
propulsion system analysis is loosely coupled to the 
overall mission performance analysis. This results 
in a time consuming iterative process. First, the 
engine is designed and analyzed. Then, the results 
from this analysis are used in a mission analysis to 
determine the overall aircraft performance. The 
results from the mission analysis are used as a guide 
as the engine is redesigned and the entire process 
repeated. In IPAS, the propulsion system, airframe, 
and mission are closely coupled. The propulsion 
system analysis code is directly integrated into the 
mission analysis code. This allows the propulsion 
design parameters to be optimized along with the 
airframe and mission design parameters, 
significantly reducing the time required to obtain an 
optimized solution. 

Introduction 

The purpose of performing a mission analysis within 
the Aeropropulsion Analysis Office (AAO) at the 
NASA Lewis Research Center is to assess the 
benefits of advanced propulsion concepts and 
technologies for future airbreathing aerospace 
vehicles. This assessment is based on the 
performance of the vehicle over a particular mission. 
This process is depicted in Figure L For each 
system being studied it is necessary to determine the 
combination of aircraft and engine design variables 


that will yield the optimum solution. It is necessary 
to determine the best match for this system in order 
to adequately compare it to other possible solutions. 

The overall performance of the aircraft and 
propulsion system is determined from computer 
simulations which combine the characteristics of the 
engine, airframe, and mission as shown in Figure 2. 

The traditional method is one in which the 
propulsion analysis and mission analysis are handled 
separately. The first step is to analyze the 
propulsion system. This is done by creating a 
computer simulation of the engine. The computer 
simulation is then used to generate a table of 
performance data. This data table contains fuel 
consumption as a function of Mach Number, 
altitude, and thrust level. A weight assessment of 
the total propulsion system is also conducted. This 
information will then be used to perform a mission 
analysis. 

A mission analysis combines engine data from the 
propulsion analysis with aircraft aerodynamic and 
weight data to determine overall performance results 
such as takeoff gross weight (TOGW) and takeoff 
field length (TOFL). The mission analysis code 
does allow for variations in the aircraft design 
variables of engine size and wing size. Thus, it is 
possible to determine the optimum aircraft solution 
for a fixed engine design. This can either be done 
by using an optimizer or by the graphical thumbprint 
method. A typical thumbprint is shown in Figure 3. 
The thumbprint shows aircraft gross weight as a 
function of engine size and wing size. The optimum 
solution is the lightest aircraft that satisfies the 
constraints. This solution is the design indicated by 
the solid circle. The arrows indicate the path taken 



by an optimizer from the initial guess (represented 
by an open circle). However, the mission code does 
not allow for variations in engine design parameters. 
The engine design is fixed at the time the engine 
data is produced. In order to determine the optimum 
combination of aircraft and engine design it is 
necessary to try many different engine designs. For 
each engine design the optimum aircraft solution is 
determined. These optimum solutions are then 
compared to determine the best overall design 
choice. This method can be very time consuming. 
It is shown in Figure 4. 

This process has been improved by directly coupling 
the propulsion analysis codes and mission analysis 
codes with an optimizer. The engineer defines the 
baseline aircraft and cycle. The optimizer acts as 
the main program, running the analysis and 
changing the design parameters to arrive at a 
solution. This method, called IP AS, is shown in 
Figure 5. IP AS would gready reduce the time 
required to reach an optimum solution by 
performing all the design iterations necessary. The 
engineer would be free to spend more time 
analyzing results and developing new 
configurations. 

This paper will describe the analysis codes used in 
IPAS and the methods used to link them. This paper 
will also give an example of IPAS being applied to a 
supersonic transport mission. The goal of the 
analysis is to determine the minimum TOGW 
aircraft subject to the constraints of noise and TOFL. 


Integration of Analysis Codes 

Five analysis codes are direcdy coupled in IPAS. 
The cycle analysis code used is NEPP, the NASA 
Engine Performance Program (ref. 1). The mission 
analysis code used is FLOPS, the FLight 
Optimization System (ref. 2). The engine weights 
are computed using WATE, Weight Analysis of 
Turbine Engines (ref. 3). The inlet and nozzle 
performance are calculated using INSTAL (ref. 4). 
The noise analysis is calculated using FOOTPR (ref. 
5). 


Cycle Analysis 

NEPP is an engine simulation code that will perform 
one dimensional steady state thermodynamic 


analysis of turbine engine cycles. Engine 
performance is calculated using component 
performance maps. The engine is defined by 
describing the flowpath that connects the 
components and the controls necessary to balance 
the engine. These controls tell the code how to 
balance the engine by listing what parameters can be 
varied and what values have to be matched Once 
the engine and control scheme have been defined it 
is possible to generate performance data. 

In order run NEPP as a subroutine, it is necessary to 
have the control scheme fixed before executing 
IPAS. This can prove to be difficult. Often, when 
running NEPP stand alone it is necessary to modify 
the input in some way to get an answer. This may 
be done by turning an additional control on or 
changing the spacing between points. An example 
of this would be increasing the number of points in 
the throttle curve so NEPP can take smaller steps in 
thrust level. This option is not available when 
running NEPP as a subroutine. The control scheme 
must be able to handle any situation that may occur. 
If it is not able to then it must be modified There 
may be cases when the cycle proves to be too 
complex to run concurrently. A good check is to run 
an engine envelope similar to what the mission code 
would require. If it is possible to get all the engine 
data by only varying altitude, Mach Number, and 
power setting, then it is a good sign that the control 
scheme is adequate. If the NEPP simulation does 
not give consistent results then the control scheme 
must be modified 

Once NEPP had been modified to work as a 
subroutine, the next step was to determine how to 
exchange propulsion data between it and the mission 
code. The first method that was tried was a direct 
method. Every time the mission analysis needed 
propulsion data, the cycle analysis code was 
executed. This proved to be a very time consuming 
way of doing things due to the large number of 
mission propulsion calls. One method employed to 
try to speed up this process was to create a running 
library of engine data. Tolerance levels were input 
by the user. If the propulsion input values of 
altitude, Mach number, and thrust, were all within 
the tolerance level of a previous call the output data 
from the previous point were used. If the input 
values were not within tolerance level, NEPP would 
be executed and the data from this case would be 
added to the library. This method was successful in 
greatly shortening the execution time without having 
a large effect on the accuracy. 
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Another approach to exchanging data between 
NEPP and FLOPS was the use of an automatic table 
generator. A table generator had already been 
developed and incorporated into the FLOPS code 
using the cycle analysis code QNEP (ref. 6). The 
QNEP routines were removed and replaced with 
NEPP routines. Before the mission was run, NEPP 
would generate a full envelope of propulsion data 
including any propulsion data needed for such things 
as noise calculations. This method had several 
advantages over the previous one. NEPP uses the 
previous converged case as a starting point for the 
next case. When using a table generator the spacing 
and order of the engine data points is controlled 
Since the engine data requests are in order, this 
yields small steps between engine points. This 
makes NEPP run much smoother and more reliably. 
It is also a more organized procedure since all the 
engine related data is generated at one time. This is 
the method that was used for all of the examples 
presented in this paper. 

Installation 

The next step in integrating the codes was to define 
the inlet operation. In order to use the INSTAL 
code it is necessary to define a performance map 
and a capture area for the inlet. The performance 
map is read from a database. The capture area was 
determined by the quantity of airflow the engine 
needed at cruise. Assuming no spillage, the inlet 
should supply just enough air for the engine. The 
capture area was determined by running a sample 
cruise point and sizing the inlet to provide the 
airflow required. 

Noise 

The next step in integrating the analysis codes was 
to include the noise computation. FOOTPR had 
already been integrated into FLOPS, The only thing 
that had to be done was to automatically generate 
the propulsion related FOOTPR inputs. For this 
supersonic transport case it was assumed that the jet 
was the dominant noise source. The engine related 
noise data was determined by generating a throttle 
curve at an altitude of 500 feet and a Mach Number 
of .30. This point is assumed to be representative of 
the entire takeoff. The throttle curve has jet 
velocity, area, and temperature, as a function of 
power setting. This data is combined with a takeoff 
trajectory generated by FLOPS and input into 
FOOTPR to determine the takeoff noise. 


Engine Weight 

The final step in linking the analysis codes was to 
find a way to determine the engine weight and size 
as a function of the design variables involved. The 
engine weight and geometric flowpath are calculated 
using the WATE code. This flowpath is determined 
by combining NEPP output, cycle conditions, with 
WATE aero-mechanical inputs, Mach Numbers, 
turbine loadings, etc. The user must determine if 
this flowpath is acceptable. If it is not then the 
WATE inputs must be modified and the case rerun. 
Figure 6 shows an acceptable flowpath. This was 
generated by adjusting the WATE inputs until the 
components lined up. The pressure ratio of this 
engine was then increased without changing the 
WATE inputs. This resulted in Figure 7. Obviously 
the turbine is too far out. What would be required is 
to add a turbine stage or increase the turbine loading 
to bring the turbine in. It would be up to the user to 
modify these inputs until an acceptable flowpath is 
obtained. This make WATE an interactive code by 
nature. Several methods were tried to make WATE 
non interactive in IP AS. 

The first method that was tried was to have IP AS 
automatically adjust the WATE inputs until an 
acceptable flowpath was obtained. Simple rules 
were written that told IPAS what an acceptable 
flowpath was and what inputs to change if it was not 
acceptable. This method was partially successful. 
IPAS was able to generate engines with reasonable 
geometries. However, this method did not work 
well with the optimizer. A small change in the 
design overall pressure ratio could result in a 
compressor or turbine stage being added or dropped. 
This will cause a step change in the engine weight. 
This is shown in Figure 8. The optimization 
techniques currently being used were unable to cope 
with this sudden change. In addition, these rules are 
specific to the engine being used in this study. A 
new system of rules would have to be produced for 
every new cycle studied. 

The next method that was tried was to map the 
engine weight as a function of the design parameters 
involved. Generating this type of map is a time 
consuming process. This is not a desirable way for 
determining engine weights in IPAS. The most 
efficient way of determining the weight of this 
engine was found by plotting the engine weight as a 
function of the design airflow. Figure 9 shows 
engine weight plotted as a function of the design 
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airflow over a wide range of values of the design 
parameters involved This indicates that for the 
engine used in this study it is possible to schedule 
the weight as a function of the design airflow only. 
This is the method that was used in this paper. This 
trend is specific to the engine being studied in this 
paper. It may not hold for different cycles with 
different design parameters. A more general method 
for determining engine weight should be developed 
for the DPAS system. 

The nozzle and inlet weights were calculated using 
the data in Figures 10 and 11. These figures 
represent semi-analytical algorithms generated at 
NAS A- Lew is. The inlet weight was a direct 

function of the capture area. The capture area was 
determined when the inlet is sized by the INSTAL 
code. The nozzle weight was a function of the jet 
velocity and airflow at takeoff. The airflow and jet 
velocity were calculated using NEPP. 

.Ogrimiser 

For these example cases the FLOPS internal 
optimizer was used The FLOPS optimizer uses the 
Sequence of Unconstrained Minimizations 
Technique with a Fiacco-McCormmick penalty 
function with quadratic extension. 

This optimizer proved to be very difficult to use. 
For many of the cases presented in this paper it took 
several runs before what were believed to be 
optimum results were achieved. There were several 
warning signs that were looked for to determine 
whether or not the solutions obtained were the true 
optimums. The first sign that a solution was bad 
was if the constraints were not met at all. The 
second warning sign was if a constraint was met by 
a large margin. For example, if the takeoff field 
length was well below the allowable limit it meant 
that the airplane could possibly use a smaller, lighter 
engine then the optimizer indicated Common sense 
was applied to the results to see if they made sense 
or not. If they did not the optimizer set up would be 
modified and the case rerun. This was done by 
varying the starting point or changing other 
optimizer inputs. There was no scientific method to 
this. The inputs were changed until the results were 
reasonable. This brought out another major 

weakness in the IP AS system. Currently the 
optimization schemes being used are unreliable. If 
IPAS is to be used to its fullest potential then the 
optimizer must be able to find the true solution with 
a minimal amount of work. 


1BE Engine 

The engine chosen for this study was an advanced- 
technology turbine bypass engine (TBE) (ref. 7). 
This type of engine has been identified as one of the 
promising candidate cycles for a next-generation 
supersonic transport. The basic engine cycle is 
similar to that of a turbojet operating with fixed area 
choked turbines. The advantage of the TBE over the 
turbojet is a bypass valve which allows the cycle to 
maintain constant turbine corrected airflow 
throughout the flight envelope without throttling. 
By bypassing a minimal amount of compressor 
discharge air around the burner and turbines, liigher 
cycle pressures and temperatures can be achieved 
which yield greater specific thrust In addition, 
varying the bypass flow for cruise power 
adjustments helps balance turbine horsepower and 
airflow requirements thereby allowing lower burner 
temperatures for more efficient cruise. The net 
effect of the turbine bypass system is high specific 
thrust at sustained airflows resulting in less spillage 
and boattail drag. A schematic of the TBE is 
presented in Figure 12. 

A NEPP cycle simulation of the TBE has been 
developed for use in the HSR, High Speed Research 
program at NASA Lewis. This simulation was used 
for this study. There were, however, several 
modifications that had to be made to prepare the 
TBE for use in EPAS. 

The first modification was to adjust the control 
scheme to run automatically. This was 
accomplished successfully with a minimal amount 
of trouble. The next modification was to map 
certain engine parameters as a function of the design 
variables. The design compressor efficiency was 
scheduled as function of the design compressor 
pressure ratio. This can be seen in Figure 13. The 
amount of cooling flow required was scheduled as a 
function of the maximum turbine inlet temperature. 
This can be seen in Figure 14. Thus, when the 
optimizer changes a design variable the affect of 
these changes on the individual components is 
automatically taken into account. 


Description of Sample Problem 
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The test problem for IPAS was a Mach 2.4 high 
speed civil transport with a 6500 nautical mile 
mission. The aircraft was equipped with four 
turbine bypass engines. The aircraft was constrained 
to a takeoff field length of 1 1000 feet and FAR stage 
III noise requirements. 

The aircraft design variables were sea level static 
thrust per engine, wing area, and takeoff scaling 
factor (TSF). The TSF represents the amount the 
engine is oversized at takeoff. For example 1.25 
indicates that the engine is 25 per cent oversized at 
takeoff. This means that 1/1.25 or 80 per cent of the 
full power thrust is used during takeoff. This is 
done to reduce the jet velocity. The engine design 
variables were maximum turbine inlet temperature 
(T4 Maximum) and the engine overall pressure ratio 
(OPR). 

The solution to this problem was the design that 
yielded the lightest aircraft and also satisfied the 
constraints. The desired objective function drove 
the design variables one direction while the 
constraints may have driven the design variables 
another direction. 

The desire to have a light weight aircraft drove the 
design process. The engine and wing should 
generally be as small as possible to minimize the 
weight of these components. The maximum turbine 
inlet temperature should be as high as possible to 
maximize specific thrust. The overall pressure ratio 
should be as high as allowable to maximize cycle 
efficiency. 

The coastraints also drove the design variables. The 
takeoff field length is determined by the engine size, 
wing size, takeoff scaling factor, and overall gross 
weight. Any increase in engine size, wing size, or a 
decrease in takeoff scaling factor will have a strong 
tendency to decrease the takeoff field length. The 
takeoff noise is driven by the maximum turbine inlet 
temperature and the takeoff scaling factor. A 
decrease in the maximum turbine inlet temperature 
or an increase in the takeoff scaling factor will 
decrease the jet velocity. Since jet velocity is the 
driving force in noise, this will result in lower noise 
levels. 

Noise is also controlled through nozzle suppression. 
Currently this is an active area of research in the 
HSR program. Noise reduction can be achieved by 
the use of a mixer/ejector nozzle, shown in Figure 
12, which will entrain large amounts of ambient air 


and mix it with high velocity air from the engine 
during takeoff. This results in lower jet velocities 
and lower noise levels. Nozzle suppression is the 
amount of noise reduction this process will yield 
when compared to ideally expanded conical jet of 
the primary stream. The overall noise levels are 
calculated by taking the FOOTPR results, which 
assumes a conical jet, and subtracting the amount of 
assumed nozzle suppression. At the present time it 
is assumed that an advanced ejector nozzle will 
yield between 10 dB and 20 dB of nozzle 
suppression. 


Re sul ts 

Several example problems were run to test the 
viability of IPAS. As stated before, the basic 
problem was to devise a solution for a Mach 2.4 
6500 nautical mile supersonic cruise mission with 
four TBE engines. The problem was to find the 
minimum TOGW aircraft subject to the constraints 
of FAR stage III noise requirements and a TOFL of 
11000 feet. 

First Example Problem 

The first example problem was performed to show 
how this system could be used to speed up the 
process of finding the true optimum match between 
cycle, aircraft, and mission. Three cases were run. 
The first case was a baseline. The second case was 
run with the engine design parameters fixed and the 
aircraft design parameters allowed to vary. The 
third case was run with all the design parameters 
allowed to vary. For each of these cases the nozzle 
suppression level was assumed to be 15dB. 

The results from these three cases can be seen in 
Figures 15, which shows the values of takeoff gross 
weight for each case. 

For the first case the engine design variables were 
frozen at values that the engineer working on the 
TBE initially thought would yield an optimum 
solution. The nozzle suppression level was assumed 
to be 15 dB. This case was run with only a takeoff 
field constraint being considered. There was no 
noise constraint. The optimizer was allowed to vary 
the aircraft design variables of engine and wing size. 
This case was used as a baseline. The takeoff field 
length constraint was met but the noise was well 
above allowable. This case was used to compare 
with the next two cases to determine the magnitude 
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of the weight penalty necessary to meet the noise 
constraint. 

The second case was run with the noise constraint. 
The engine design variables were still not allowed to 
vary. The only way to solve the noise problem was 
to oversize the engine. This case represents the 
initial solution to the problem using the engine 
originally thought to be the best solution. Both the 
takeoff field length and noise constraints were met. 
However, to meet the noise constraint the engine 
had to be oversized by 39 per cent at takeoff. This 
resulted in a significant TOGW penalty of 11 per 
cent as seen in Figure 15. 

The third case was run with the engine design 
parameters, OPR and T4 Maximum, allowed to 
vary. Once again both the takeoff field length and 
noise constraints were met. However, since the 
engine parameters were allowed to vary, the noise 
constraint was met through a combination of 
lowering T4 Maximum and oversizing the engine. 
OPR stayed close to the maximum allowable value 
of 17.5 to maintain higher propulsive efficiency. 
The result was a smaller engine and a better match 
between engine, airframe and mission yielding a 
TOGW penalty of only 5.1 per cent as seen in 
Figure 15. This is a weight savings of over 5 per 
cent compared to the second case. 

This is the solution an engineer would eventually 
achieve using the traditional approach. However, 
many iterations at different levels of OPR and T4 
Maximum would be required. Using the IPAS 
system it is possible to obtain the solution in one 
optimized run. This results in a time savings of 
approximately 80 per cent. 

Second Example Problem 

The second example problem was a variation of the 
first. For this problem it was decided to determine 
the affect of nozzle suppression level on the overall 
results. This was done by changing the amount of 
nozzle suppression and determining a new optimized 
solution. Trying to determine this effect the 
traditional way would require studying many 
different engines to determine the engine design that 
is optimum for each suppression level. Using the 
new system it is only necessary to change the 
suppression level in the input deck. The value of 
OPR was fixed at its maximum allowable value for 
the sake of simplicity. 


Three cases were run for this example; assuming 
nozzle noise suppression levels of 10 dB, 15 dB, and 
20 dB. 

The results for these cases can be seen in Figures 16. 
Both the takeoff field length and noise constraints 
were met for all the cases. Figure 16 shows the 
aircraft weight as a function of nozzle suppression. 
As the amount of assumed nozzle suppression 
decreases the TOGW increases. This is because as 
the nozzle suppression goes down other tradeoffs, 
such as oversizing the engine and lowering the 
maximum turbine inlet temperature, must be made 
to meet the noise requirement. These methods 
decrease the noise but they also increase the weight. 

This is an excellent example of how this system 
could be used for sensitivity studies. Suppose you 
were unsure of the level of suppression that could be 
obtained. Figure 16 shows how important nozzle 
suppression is to the overall problem. If takeoff 
gross weight is a strong function of the suppression 
level, as in this case, it is very important to invest 
time and money into maximizing the nozzle 
suppression. 

Using the old method of iteration it would take 
approximately three weeks to obtain these results. 
Using the new method it would only take an 
estimated three optimized runs, about three days. 

A major concern involved in this type of problem is 
how much CPU time is required to get a solution. 
The case with all five parameters allowed to vary 
required about 5 hours of CPU time on an IBM 
RS6000 550 workstation while the case with only 
two parameters allowed to varied required about 1.5 
hours of CPU time. With the improvements being 
made in computer technology, this time is likely to 
decrease rapidly. 


C ot cIws wp 

The Integrated Propulsion/Airframe Analysis 
System shows great promise in the analysis of 
advanced airbreathing aerospace systems. When 
coupled with an optimizer, it allows solutions to be 
obtained in 1/5 the time previously required. 

There are, however, limitations to keep in mind. In 
order to run a case like this it must be possible to set 
the problem up so that all the codes can run non 
interactively. This could be difficult to do. If it is 
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not possible to get a reliable NEPP control scheme 
set up or if it is not possible to devise a scheme to 
determine engine weights then the traditional 
interactive approach must be used 


Future Work 

There are two areas of work needed to make this 
type of system more useful. First, some way must 
be developed to generate the engine weight as the 
design variables change. For the TBE it was 
adequate to scale the weight as a function of the 
design airflow. This will not be the case for other 
cycles. 

Second, a better optimization scheme is needed. 
Currently, the optimizer will often get lost in the 
design space. Even when a constrained solution is 
reached, it is often not the optimum solution. If this 
system is to be used to its potential then the 
optimization scheme must give consistent results. 

Finally, it is expected that the computational speed 
of this system can be greatly increased through the 
use of parallel processing. 
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Figure 1. Aircraft Analysis Procedure 



Figure 2. Aircraft Analysis System 
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Figure 3. Aircraft Sizing Thumbprint 
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Figure 6. Acceptable TBE Flowpath 
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Figure 8. Step Increment in Engine Weight 
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Figure 9. TBE Engine Weight Method Used 
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Figure 10. Mixer / Ejector Nozzle Weight 



Figure 11. Inlet Weight 
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Figure 12. Schematic ofTBE with Mixer / Ejector Nozzle 
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Figure 15. Comparison of Traditional and 
Concurrent Methods 
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Figure 16. TOGW vs Nozzle Suppression 
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